1. Field of the Invention
The present invention generally relates to the art of universal serial bus (USB) systems, and more particularly, to a method and apparatus for posting write data requests.
2. Description of the Relevant Art
The USB specification is a proposed standard recently promulgated by a group of companies including Compaq Computer Corporation, Digital Equipment Corporation, International Business Machines Corporation, Intel Corporation, Microsoft Corporation, and Northern Telecom Limited. Described below are various aspects of the USB relevant to a complete understanding of the present invention. Further background concerning the USB may be obtained from USB Specification, Revision 1.0 which is incorporated herein by reference.
The USB is a cable bus which supports data exchange between a host computer and a wide range of peripheral devices. The USB provides two wire, point-to-point signaling in which the signals are differentially driven at a bit rate of 12 megabits per second.
USB systems are generally defined in terms of (1) interconnects, (2) devices, and (3) hosts. The USB interconnect defines the manner in which the USB devices are connected to and communicate with the USB host. There is generally only one host on any USB system. A USB interface to the host computer system is referred to as the host controller. The host controller may be implemented in a combination of hardware, firmware, or software. USB devices are defined as (1) hubs, which provide additional attachment points to the USB, or (2) finctions, which provide capabilities to the system; e.g., an ISDN connection, a digital joystick, or speakers. Hubs indicate the attachment or removal of a USB device in its per port status bit. The host determines if a newly attached USB device is a hub or a function and assigns a unique USB address to the USB device. All USB devices are accessed by a unique USB address. Each device additionally supports one or more endpoints with which the host may communicate. The remaining description will be limited to USB devices defined as functions.
The USB supports functional data and control exchange between the USB host and USB devices. USB data transfers take place between host software and a particular endpoint on a USB device. The USB architecture comprehends three basic types of data transfer: (1) isochronous or streaming real time data which occupies a prenegotiated amount of USB bandwidth with a prenegotiated latency; (2) asynchronous interactive data such as characters or coordinates with human perceptible echo or feedback response characteristics, and; (3) asynchronous block transfer data which is generated or consumed in relatively large and bursty quantities and has wide dynamic latitude and transmission constraints.
The USB host interacts with USB devices through the host controller. The host controller is responsible for detecting the attachment and removal of USB devices, managing control flow between the host and USB devices, managing data flow between the host and USB devices, collecting status and activity statistics, and providing a limited amount of power to attached USB devices. The USB system software on the host manages interactions between the USB devices and device software. There are five areas of interactions between the USB system software and device software. They include: (1) device enumeration and configuration; (2) isochronous data transfers; (3) asynchronous data transfers; (4) power management, and; (5) device and bus management information.
Bus transactions including data transfers generally involve the transmission of three different packets, e.g. Token, Data, and Handshake. All packets begin with a SYNC field, which is used by input circuitry to align incoming data with a local clock. A packet identifier (PID) immediately follows the SYNC field of every USB packet. The PID consists of a four-bit ID field followed by a four-bit check field. The PID indicates the type of packet (e.g., Token, Data, and Handshake) and the format of the packet along with the type of variant detection applied to the packet. The four-bit check field of the PID insures reliable decoding.
Token packets include an ADDR field which specifies the target USB device, via its USB address, that is the source or destination of a Data packet, depending on the value of the Token PID. USB devices must perform a complete decoding of the ADDR field.
A Data packet includes a data field which may range from zero to N bytes and must be in integral numbers of bytes. Data bits within each byte are shifted out most significant bit first. The data field of a Data packet is divided into fields which give extra information to the USB device regarding the request being made. One field, the command code, tells what the targeted USB device should do, such as set up a read from a USB device space or set up a write to a USB device space. The read space command is used to request information from a given location in a given space of a USB device. The command is used to set up the read, which is followed by a request from the host for the USB device to send data. The USB device then sends the data it has retrieved from the previously specified space. The write space command uses exactly the same definition as the read space command. However, the Data packet contains data transferred by the host to the USB device.
Handshake packets consist of only a PID. Handshake packets are used to report the status of a data transfer, and can return values indicating successful reception of data, CRC failure, flow control, and certain fault conditions.
Each data transfer begins when the host controller, on a scheduled basis, sends a Token packet describing the type of transfer (e.g. write to or read from USB device), the USB address of the targeted USB device, and an endpoint number therein. The USB device addressed in the Token Packet selects itself by decoding the appropriate address field ADDR. In any given data transfer, data is transferred either from the host to a device (e.g. write data transfer) or from a device to the host (e.g. read data transfer) depending on the Token Packet's PID.
In the case where the host sends or writes data, the target USB device decodes the incoming Token's ADDR. If the USB device's address matches ADDR of the Token, the USB device accepts a subsequent host provided Data packet containing write data and internal USB addresses where the data is to be written. At the end of the transmission, the USB device performs a CRC check over the data portion of the packet and uses the result to determine if the data transfer was successful. The USB device replies with a Handshake which informs the host of the outcome.
In the case where the host seeks to read data from a USB device, the host must issue two sets of packets. The first set of packets is used to set up the read operation in the USB device. The second set of packets is used to actually send the requested data to the host. If the decoded address in the first Token matches that assigned to the targeted USB device, the targeted USB device is alerted that the host will send a Data packet containing the command codes necessary for setting up the read operation in the device. Subsequent thereto, the host issues the Data packet containing those command codes. The command codes include the address or addresses internal to the targeted USB device where the requested data is stored. The targeted USB device returns a Handshake acknowledging proper receipt of the first Data packet while requested data is being transferred to a packet buffer. The host then issues a second Token packet requesting the targeted USB device to send data. In response, the USB sends the Data packet containing the requested data. Finally, the host device transmits a Handshake packet to the targeted USB device acknowledging proper receipt of the requested data.
USB devices have two different kinds of logical buffers: packet buffer and elasticity buffer. The host never directly accesses these buffers. However, the characteristics of these buffers must be known to the host in order for the correct bounds for packet sizes to be established. The packet buffer determines the maximum packet size which the USB device can receive or send. This is conceptually a "latch" directly attached to a USB interface which initially receives packets from and sends packets to the USB. From here, the USB device will appropriately dispatch to other areas within the USB device, data received from the host, or dispatch to the host a packet containing data received from the other areas within the USB device, depending on commands received from the host and the USB device's internal division of labor.
Port consolidation for existing devices is a primary goal for USB. It follows that existing peripheral devices like GPIB controller IC's, serial UART's, or DAQ circuitries will migrate to the USB in the future to free up much needed port/connector space and to reduce form factors. Port consolidation of existing devices will occur gradually over time. To facilitate the acceptance of USB as the primary bus, a mechanism must be provided which supports existing devices and their protocol on the USB.
FIG. 1 shows a pre-USB system in which an I/O driver 10 of a host computer 12 is coupled to a peripheral I/O device 14 via, for example, a PCI or ISA bus interface circuit. The I/O device 14 could be almost any register based circuitry (for example, a GPIB controller IC, serial UART, or DAQ circuitry). This system implements a register based communication wherein I/O driver 10 models the I/O device 14 as a group of hardware registers. In this configuration, the I/O driver 10 accesses I/O device 14 by issuing individual requests to read or write data to one of the registers in I/O device 14. The I/O device 14 quickly responds by returning data from or writing to the designated register.
FIG. 2 shows the system of FIG. 1 supported for communication over a USB 18. Host computer 12 includes the I/O driver 10 implemented in the non-USB system shown in FIG. 1. Additionally, host computer 12 includes a USB driver 16 and USB interface logic circuit 20. The I/O driver 10 continues to model the I/O device 14 as a group of registers. To access a hardware register in I/O device 14, however, the I/O driver first passes its read or write data request to the USB driver 16 which coordinates construction and transmission of the Token, Data and Handshake packets required by USB protocol for transferring data to or from the I/O device 14. CPU with USB port (device interface) 22 is connected to I/O device 14 and is configured by firmware 24 to act as an interface allowing I/O device 14 to communicate with the host via the USB 18. Device interface 22 receives and decodes incoming packets (e.g. host generated Token packets) and generates complimentary Data or Handshake packets needed to complete a data transfer between I/O device 14 and host computer 12.
While the USB driver 16 and USB logic circuit 20 allow host computer 12 to communicate with I/O device 14 via USB 18, the I/O driver 10 still maintains its pre-USB protocol of modeling the I/O device 12 as a group of hardware registers. Each read or write request requires its own individual bus transaction for completion. Given that each USB bus transaction involves one or more sets of packets (Token, Data, Handshake) a significant amount of system overhead is required for each read or write request generated by the USB-based system of FIG. 2. This is particularly true when comparing the overhead of bus transfer for the non-USB system of FIG. 1. The increase in system overhead, in turn, limits the speed at which data communication is effectuated between the host computer 12 and the I/O device 14 shown in FIG. 2.